1. Field of the Invention
The present invention relates to an execution apparatus for executing a function in response to a request received via a network, and to a method of accepting a request received via a network.
2. Description of the Related Art
Office equipment and equipment for domestic use now come equipped with a function for implementing linkage with processing provided via a network.
A technique available for implementing such linkage with processing provided via a network is UPnP (Universal Plug and Play). UPnP is a technique for exchanging interface information of a device and for calling a function. Other techniques having a similar purpose and function are Jini and Nxta, etc.
With UPnP, interface information has been standardized in relation to several device types. Therefore, in a case where the function of a particular type device can be checked in advance, it is possible to adopt a configuration that pre-installs processing corresponding to the interface information. However, in a case where a standardized specification is expanded on one's own in order to maximize a device-specific function or a case where a standard specification itself has been expanded after device development, the handling of interface information relating to the expanded portion cannot be decided beforehand.
UPnP described above mainly targets a home network consisting of domestic equipment. However, Web service is available as a similar technique in business networks consisting of office equipment.
Web service is a versatile technique capable of supporting a variety of scales and types from large-scale systems that take charge of commercial transactions between enterprises to stand-alone items of office equipment. For this reason, it is predicted that a style in which a plurality of Web services are connected together to construct business solutions or applications will become the mainstream in next-generation software development.
In a Web service, interface information is defined by WSDL (Web Service Description Language). There are many cases where interface information using WSDL includes content that is more complicated in comparison with UPnP. For example, use can be made of a data structure defined by the developer on his own. Furthermore, with Web service, information based upon a plurality of items of message schema information can be mixed with a single SOAP (Simple Object Access Protocol) message. “Message schema information” is information that indicates message structure and method of description.
Thus, with Web service, there is a high degree of freedom in message schema information, which is interface information of the service. A device for processing this therefore requires XML (Extensible Markup Language), which is more sophisticated than UPnP, and messaging processing.
Although standard interface information has been defined in accordance with device type in UPnP, standardization relating to the content of interface information per se has not been performed in Web Service.
Furthermore, it is highly likely that the growth and expansion of business solutions of interest will be accompanied by time-to-time changes in the interface information required.
In devices that support Web service, adaptive execution of required software is sought even in circumstances where interface information changes arbitrarily. This is especially conspicuous in case of devices in which the goal is to support business solutions.
If the relationship between message schema information for using a device function and software internally of the device for interpreting and processing this information is fixed (static), the following problem arises: In an environment in which information based upon a plurality of items of message schema information is mixed with a single SOAP message, as in Web service, there is a possibility that not all of the content of received messages can be processed.
In order to deal with such circumstances, the following technique of automatically selecting adoption or rejection of software stored in a device is available:
Specifically, the technique is one used in order to perform management of a software module in which ordinary operating-system software or a part of application software is implemented. This technique is referred to as a “dynamic load library” technique. The dynamic load library technique is a technique that makes it possible to load or unload a plurality of items of library software having different functions dynamically in accordance with the application software. As long as a function provided by library software is unnecessary, the library software is not read in and executed. Further, in many computer environments, a memory image can be shared after the library software has been read in.
With this technique alone, however, a decision as to which library is necessary must be made by the application software. Accordingly, in a case where a plurality of items of message schema information and a plurality of message processing programs are interconnected, all must be decided by each individual application.
Furthermore, there is a technique whereby a program is stored, managed and executed as component software. This technique is referred to as “component container” technique. This technique is an evolution of the dynamic load library. The overall system is composed of component software for implementing individual functions and container software that is capable of storing and executing a plurality of items of the component software. A request from a user is received by the container software and the appropriate component software starts being executed depending upon the decision made by the container software. In accordance with this technique, the component software need not start execution if there is no request from a user, and it is also possible to halt the system in a case where there is no request. As a result, adaptive selection and execution of software is possible.
However, as with the dynamic load library technique, this technique merely provides an environment usable in dynamic selection of software, and this alone does not make it possible to implement automatic processing of a message processing program made to conform to message schema information.
Although these techniques are useful as fundamental processing techniques for implementing dynamic selection of adoption or rejection of software, automatic processing of a message processing program made to conform to message schema information cannot be implemented solely by these stand-alone techniques. In addition, interface information in the local device itself cannot be updated.
Furthermore, the following techniques are described in patent documents.
First, a technique described in Japanese Patent Application Laid-Open No. 2003-162533 provides a schema unification conversion system in which schemas can be unified even without a database used for the same application. With the schema unification conversion system, a plurality of different data schemas are generated beforehand from data referred to as an “abstract schema graph”, thereby achieving unification.
However, with the approach using an abstract schema set forth in Japanese Patent Application Laid-Open No. 2003-162533, the degree of freedom of message schema information is high in message exchange in a device that uses Web Service, as mentioned above, and there is no assurance that the message schema information handled can be restored to an abstract schema.
Next, a technique described in Japanese Patent Application Laid-Open No. 7-121358 makes it possible to automatically reflect a result in creation of specifications conforming to a program specialization request and in the program creation operation when the specifications of a program are created. According to this technique, a program specializing apparatus specializes program prototype information and generates program specifications based upon program prototype information and data definition assignment information with respect to external data. The purpose is to rapidly develop a program corresponding to a data definition at the time of program development.
With the technique described in Japanese Patent Application Laid-Open No. 7-121358, however, a program cannot be changed over using a data definition as the key at the time of program execution. That is, dynamic automatic processing of a message processing program made to conform to message schema information at the time of execution cannot be implemented.
Furthermore, a technique described in Japanese Patent Application Laid-Open No. 9-138760 has as its object to implement a mechanism for calling a suitable message handler by managing entry of a message handler dynamically at the time of execution. By attaching a unique identifier world-wide to an operation or data in an exchanged message, an appropriate message handler is searched for and, if one exists, this handler is selected. If one does not exist, then an appropriate program module is loaded/linked, a message handler in the module is selected and the selected handler is called.
According to the technique described in Japanese Patent Application Laid-Open No. 9-138760, however, the instance of a message is furnished with an ID that is capable of specifying a program that processes this, and therefore ID assignment must be handled as an item of understanding between the sending and receiving sides of the message. In message exchange in a device using Web service, it cannot be expected that such an ID will always be assigned in the message schema information handled. Further, since schema processing is not applied to a message sent and received, interface information in the local device cannot be updated.
Thus, the prior art provides some solutions to the problems of processing efficiency relating to software and versatile handling of message schema. However, in circumstances where interface information is changed, as in Web service in a case where a business solution is supported, the prior art does not provide a satisfactory solution to the problem of adaptive execution of necessary software.